Currently, the files from the data, headers, and scripts portions of a
wheel don't end up in the proper sub-directories of the venv. This
means the full files of a distribution aren't available at the typical
location in the venv, making it harder to integrate with standard
tools.

To fix, simply map the directories to paths in the venv and give them
similar treatment as site-packages.

The spec says certain first-level directories of the `.data` directory
map to specific scheme paths, which `whl_library` already handles.
Here's a listing of the
`wheel data directory -> install scheme path key -> whl_library
directory`
relationships

* purelib -> purelib -> site-packages
* platlib -> platlib -> site-packages
* headers -> include -> include
* scripts -> scripts -> bin
* data -> data -> data

Relevant reading:
* Packaging specification:

https://packaging.python.org/en/latest/specifications/binary-distribution-format
* Posix install scheme paths:
  https://docs.python.org/3/library/sysconfig.html#posix-prefix
* Windows install scheme paths:
  https://docs.python.org/3/library/sysconfig.html#nt

The whl_library rule uses posix names for extracting. When
materialized into a binary's venv, platform specific names are used:

* bin -> (posix) bin; (Windows) Scripts
* include -> (posix) include; (Windows) Include (capital i)
* data -> venv root directory

Along the way ...

* The data files (files under the "data" scheme of a whl) are now
  always included as part of depending on the library. They would be
  in included in venv_site_packages=yes mode, so this better aligns
  behavior of the two modes.
* Rename `is_venv_site_packages` to `_is_venv_site_packages_yes` to
  better represent the purpose and visibility of it.
* Make whl_from_dir support Windows. Testing of venvs relies on
  using it for testing various special cases.